Amazon EventBridgeを用いて、複数アカウントのAWS IAM Access Analyzerの検知を1つのアカウントに集約してみた
2024.01.11AWS IAM Access Analyzerをまとめて管理したい
おのやんです。
みなさん、複数アカウントのAWS IAM Access Analyzer（以下、IAM Access Analyzer）を1つのアカウントに集約したくないですか？私は集約したいです。
AWS Security Hub（以下、Security Hub）やAmazon GuardDuty（以下、GuardDuty）などのセキュリティサービスでは、複数のメンバーアカウントを管理者アカウントで管理できる機能があります。具体的には、メンバーアカウントに対して、管理者アカウントへ「招待」ができます。
一方で、他のセキュリティサービスのひとつであるIAM Access Analyzerは、デフォルトで集約する機能を持ちません。AWS Organizationsを使えば、IAM Access Analyzerを集約して管理できますが、諸事情でAWS Organizationsを使用していない場合もあります。その際には、Amazon EventBridge（以下、EventBridge）などを用いてIAM Access Analyzer集約を実装する必要があります。
ということで今回はEventBridgeを用いて、メンバーアカウントのIAM Access Analyzerを管理者アカウントに集約してみたいと思います。
構成
全体の構成は以下の図のようになります。
メンバーアカウントでは、IAM Access Analyzerが有効になっています。この検知を、EventBridgeのデフォルトバス（以下、EventBridgeバス）が受け取ります。このデフォルトパスのEventBridgeルールには、管理者アカウント側のEventBridgeバスがターゲットとして指定されています。こうすることで、管理者アカウント側のEventBridgeバスにIAM Access Analyzerの検知が送信されます。管理者アカウント側のEventBridgeルールでは、SNSトピックがターゲットとして設定されています。こうしてEventBridgeを数珠繋ぎにすることで、IAM Access Analyzerの検知をメールで送信できます。
実装してみた
それでは、IAM Access Analyzer集約を実際に実装してみましょう。なお、メンバーアカウントでIAM Access Analyzerは有効化されているものとします。
SNSの設定
まずは、管理者アカウント側でSNSの設定を行います。
まずは、SNSトピックから設定します。今回はtest-iam-access-analyzer-notificationという名前をつけました。トピックのタイプはスタンダードで進めます。
トピックの作成が完了したら、続いてSNSのサブスクリプションの設定も行いましょう。トピック詳細画面のサブスクリプションタブから、新規のサブスクリプションを作成できます。
サブスクリプションの設定では、エンドポイントのタイプとして「Eメール」を選択します。エンドポイントには、通知したいメールアドレスを入力しておきます。これらを設定できたら、サブスクリプションを作成します。
作成が完了したら、エンドポイントとして登録したメールの受信フォルダをチェックします。AWS Notification - Subscription Confirmationというタイトルのメールが届いているので、こちらを開いてみます。すると、Confirm Subscriptionというリンクが書かれたメール本文が確認できます。このConfirm Subscriptionリンクをクリックします。
ブラウザの新規タブがこのように開いたら、サブスクリプションの設定は完了です。
トピック詳細画面を開いてみると、このようにステータスが「確認済み」となっていることが確認できます。
管理アカウント側EventBridgeの設定
続いて、EventBridgeの設定を行います。
まず、管理アカウント側EventBridgeのルール画面から、ルールを作成します。
ルールの詳細定義の画面では、適当な名前をつけておきます。今回はtest-iam-access-analyzer-ruleという名前にしました。イベントバスは「デフォルト」、ルールタイプは「イベントパターンを持つルール」で設定します。
イベントパターンの構築画面では、イベントソースとして「その他」を選択します。
メソッドは「カスタムパターン (JSONエディタ)」を選択します。また、イベントパターンとして、以下のJSONを設定します。
{
"source": [
"aws.access-analyzer"
],
"detail-type": [
"Access Analyzer Finding"
],
"detail": {
"isDeleted": [
false
]
}
}
EventBridgeルールのターゲットでは、先ほど作成したSNSトピック（test-iam-access-analyzer-notification）を選択します。
EventBridgeルールが正常に作成できれば、このようにルール一覧画面にtest-iam-access-analyzer-ruleが追加されます。
次に、イベントバスのIAMポリシーを設定します。まず、EventBridgeバスの画面に移動します。今回設定しているのはdefaultバスですので、defaultバスの設定に移動します。
この「許可」タブのリソースベースのポリシーを編集し、以下のポリシーに置き換えます。
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "AllowAccountToPutEvents",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::{メンバーアカウントID}:root"
},
"Action": "events:PutEvents",
"Resource": "arn:aws:events:ap-northeast-1:{管理アカウントID}:event-bus/default"
}]
}
最後に、管理アカウントのデフォルトバスのARNをコピーしてメモしておきます。これらが終われば、管理アカウント側のEventBridgeの設定は完了です。
メンバーアカウント側EventBridgeの設定
メンバーアカウント側EventBridgeの設定項目は、基本的には管理アカウント側EventBridgeと同じです。ただし、メンバーアカウント側EventBridgeルールのターゲットは、さきほどのSNSトピックではなく、管理者アカウントのデフォルトバスになります。
そのため、ターゲット設定画面では、ターゲットタイプとして「EventBridgeイベントバス」、「別のアカウントまたはリージョンのイベントバス」を選択します。また、ターゲットとしてイベントバスの指定する際には、さきほどメモした管理者アカウントのデフォルトバスARNを入力します。
ちなみに、ここでは管理者アカウントのデフォルトバスARNから自動で実行ロールが作成されます。このロールの許可は、JSONでは次のようになります。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"events:PutEvents"
],
"Resource": [
"arn:aws:events:ap-northeast-1:{管理アカウントID}:event-bus/default"
]
}
]
}
以上が、メンバーアカウント側EventBridgeの設定になります。
検証
それでは、実際にIAMAccess Analyzerが集約されているか確認してみましょう。
今回はメンバーアカウント側のS3バケットのバケットポリシーを編集して、クロスアカウントアクセスを一時的に許可してみます。
S3バケットのバケットポリシー編集画面に移動し、以下のポリシーに設定します。
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "s3:*",
"Effect": "Allow",
"Resource": "arn:aws:s3:::{クロスアカウントアクセスを許可するS3バケットのARN}",
"Principal": {
"AWS": [
"{別アカウントのID}"
]
}
}
]
}
数分後に、このようなメールが届いていたら、正しく設定されています。モザイクをかけているため分かりにくいですが、メールの本文はIAM Access Analyzder検知のJSONになっています。
メンバーアカウントで発生したIAM Access analyzerの検知が管理者アカウントに正常に送信され、そこからメールが送信されていることがわかります。
さいごに
今回紹介した設定は、EventBridgeのルールなどを変更すれば他の集約設定にも応用可能です。マルチアカウント集約の際にOrganization以外の方法で設定する場合は、ぜひ参考にしてみて下さい。では！
